Après un an et demi, l’équipe de JRuby vient de mettre à disposition la version 1.7.0 de son implémentation de l’interpréteur Ruby écrit en Java. La grande fonctionnalité de cette version est la compatibilité avec Ruby 1.9. En effet, l’interpréteur se comportera comme un Ruby 1.9.3 par défaut. Il y a encore des bouts de Ruby 1.9 qui ne sont pas — encore — pris en charge comme le Ripper, l’analyseur de code. Cependant, l’équipe considère que cette version est capable de faire tourner des applications en production.
Le travail ne s’est pas fait que là. L’équipe JRuby annonce des améliorations dans tous les sous‐systèmes et notamment dans la parallélisation des traitements. L’autre point saillant de cette version est la prise en charge de la fonctionnalité invokedynamic incluse dans la JVM depuis la version 7 de Java (mais désactivée par défaut jusqu’à l’arrivée de Java 8). JRuby vous explique comment l’activer.
JRuby est disponible en téléchargement sous forme de binaires pour Java, d’exécutables pour Mac OS X et Windows, de gems Ruby et, bien sûr, de fichiers sources. Vous pouvez également cloner le dépôt Git !
NdM : Merci à Nÿco et Le Cancre Las pour leur participation à la rédaction.
Rappels sur JRuby
JRuby est une implémentation libre (sous triple licence CPL, GPL et LGPL) en Java du langage de programmation Ruby. Son étroite intégration avec Java permet d’embarquer l’interpréteur Ruby directement dans une application Java, avec des liens bidirectionnels possibles entre les deux langages, à la manière de Jython (Python en Java). La prise en charge de Ruby on Rails est de la partie !
Parmi les autres nouveautés
On retrouve :
- tous les problèmes d’encodages liés à la 1.9 sont résolus ;
- l’instruction
Kernel#exec
réalise désormais un appel natif sur toutes les plates‐formes ; - améliorations et corrections relatives à l’intégration Java ;
- les fonctions natives sont mieux prises en charge sur Solaris, Linux pour ARM, etc. ;
- mise à jour vers les bibliothèques standard de Ruby 1.9.3p286 ;
- mises à jour de Rubygems 1.8.24 et Rake 0.9.2.2 ;
- enfin, notez l’abandon de Java 5. Java 6 est un pré‐requis pour embarquer JRuby.
Feuille de route
L’équipe prévoit désormais de sortir des versions mineures de la branche 1.7.x toutes les 2 à 3 semaines, afin de corriger les problèmes rencontrés et de finaliser la prise en charge des parties manquantes des bibliothèques de la version 1.9 de Ruby.
Aller plus loin
- Annonce de JRuby 1.7.0 (41 clics)
- Site officiel de JRuby (68 clics)
- Télécharger JRuby (21 clics)
- Dépôt Git de JRuby (16 clics)
# Les performances ?
Posté par gasche . Évalué à 4.
Ça va vite, il y a de jolis dessins à montrer ? En comparant à la version précédente mais aussi à l'implémentation officielle de Ruby ?
[^] # Re: Les performances ?
Posté par isildur37 . Évalué à -5.
Java troll inside?
[^] # Re: Les performances ?
Posté par djano . Évalué à 2. Dernière modification le 25 octobre 2012 à 18:03.
Oui, je suis particulièrement curieux a propos des gains de performance d' invokedynamic
Tiens voici un petit graphique ici (a partir de la diapo 18):
https://docs.google.com/presentation/d/1-hA1tAF1ADdCzsIAEQCcVxl2YIieb4Xopm21Slx3XFE/edit?pli=1#slide=id.g860ad29_0_0
Résultat: Java 7 avec invokedynamic souvent 1.5x plus rapide que Java 7 sans invokedynamic
[^] # Re: Les performances ?
Posté par djano . Évalué à 3.
Et une explication du fonctionnement de invokedynamic ici:
http://blog.headius.com/2011/08/jruby-and-java-7-what-to-expect.html
[^] # Re: Les performances ?
Posté par ckyl . Évalué à 4.
J'ai laché le suivi du JDK depuis un an donc il se peut que je dise des choses qui ne sont plus vrai (fix dans une mineur).
Dans les JDK7 l'utilisation d'invokedynamic desactive pas mal d'optimisation de Hotspot. Il était prévu d'adresser ces problèmes dans le JDK8. Il est donc a prévoir une deuxième grosse ameilloration des perfs quand Ruby sera capable d'utiliser pleinement Hotspot. J'ai pas réussi à trouvé un résumé de l'état d'Hotspot sur ce sujet. Si quelqu'un a des infos…
D'autres bonnes choses devraient arriver avec le JDK8 pour les langages dynamiques commme la suppression de l'horrible pergem space.
[^] # Re: Les performances ?
Posté par Yakulu . Évalué à 2.
Le shootout est passé à JRuby 1.7
Ça permet des comparaisons (et en 32), sur pas mal de micro-benchmarks entre cette version et l'officielle.
Sur ces tests, qui ne reflètent évidemment pas la réalité pour un programme donné :
[^] # Re: Les performances ?
Posté par dave_null (site web personnel) . Évalué à -1.
Bah déjà que l'implémentation officielle consomme beaucoup de mémoire :-)
[^] # Re: Les performances ?
Posté par ckyl . Évalué à 5.
Attention tout ce qui repose sur la JVM est assez biaisé niveau consommation mémoire puisque par design elle va utiliser sa heap size en maximum sans rien garbage collecter avant. Très grossièrement c'est comme si free(3) ne faisait rien tant qu'un certain seuil n'était pas atteind.
Donc sur tout les bench de ce type la mesure est assez inutile. Après ce comportement est ou n'est pas problématique selon les cas d'usage.
# Utilité ?
Posté par jorisd . Évalué à 6.
Bonjour
N'y voyez pas un troll, juste une question naïve : ça sert à quoi d'implementer Ruby en Java ?
[^] # Re: Utilité ?
Posté par gasche . Évalué à 4.
En gros les gens espèrent récupérer les bonnes propriétés des machines virtuelles Java optimisées à mort : compilation JIT optimisée à mort, et runtime qui supporte bien le parallélisme multi-thread (alors que les implémentations maisons reposent souvent sur un Big Interpreter Lock et ne peuvent donc faire que du parallélisme multi-process). Tant mieux si tu as en plus accès aux librairies Java (mais en pratique les interfaces sont tellement différentes que ça n'est pas si commode), aux outils qui travaillent directement sur le bytecode (test de sécurité ou de bugs, instrumentation etc.).
C'est partiellement liés aux raisons que les gens de Google ont utilisé quand ils ont écrit Gerrit, une implémentation d'un logiciel de revue de code basée sur un backend Git: au lieu de prendre l'implémentation Git officielle en C, ils utilisent une ré-implémentation de Git en java, JGit, parce qu'ils préfèrent administrer des trucs qui tournent sur la JVM.
[^] # Re: Utilité ?
Posté par xcomcmdr . Évalué à 2.
Ruby 1.9 est passé (pour la VM) de MRI à YARV, ce qui a permis d'avoir des kernel threads, qui semblent correspondre à de "vrais" threads (plutôt que les green threads des versions <= 1.8) selon wikipedia, et a apporté pas mal d'améliorations des performances.
La VM de Ruby 2.0 devrait aussi apporter une amélioration des perfs : http://www.h-online.com/open/news/item/Ruby-2-0-feature-freeze-heads-for-February-release-1736526.html
Du coup, l'intérêt de JRuby sera nettement moindre quand Ruby 2.0 sera largement adopté (oui ce n'est même pas sûr d'arriver un jour, mais bon), non ?
Aussi, en quoi Ruby (et les autres) sont "implémentés avec les pieds" exactement ? Je suis curieux. :)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Utilité ?
Posté par gasche . Évalué à 3.
Il n'empêche que l'implémentation de YARV fait qu'à un instant donné un seul thread Ruby peut s'exécuter, il y a un "Big Interpreter Lock" comme je l'ai dit dans mon message (l'intérêt d'avoir plusieurs threads dans ce cas est d'utiliser l'outillage de l'OS, de faire tourner des threads C en parallèle avec des threads Ruby (ce qui encourage les gens à coder de plus grosses parties de leur programme en C), ou encore de donner le contrôle à un autre thread si tu bloques sur une grosse entrée/sortie (mais il faut explicitement coder la relâche du verrou global)). Au contraire la JVM permet de faire tourner du bytecode vraiment en parallèle sur plusieurs cœurs, donc si tu écris tes programmes pour (il faut éviter les data races) tu pourrais avoir des gains en performance.
Je n'ai pas suivi la 2.0 mais il faudrait partir d'une source un peu plus intéressante qu'une demi-phrase sur "un bytecode plus optimisé" dans un article grand public.
[^] # Re: Utilité ?
Posté par xcomcmdr . Évalué à 1.
Hum, je vois. Donc, l'usage des threads natifs n'empêche pas le GIL, cette page le confirme : http://essenceandartifact.blogspot.fr/2011/09/sad-state-of-concurrency-in-ruby-192.html
Pour la 2.0, la roadmap est pour le moins difficile à lire, et il n'y a rien sur le GIL on dirait :
http://bugs.ruby-lang.org/projects/ruby-trunk/roadmap
Je pensais qu'il y avait un wiki avec une roadmap claire, mais impossible de le trouver.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Utilité ?
Posté par gasche . Évalué à 5. Dernière modification le 26 octobre 2012 à 17:04.
Dans la vraie vie ça ne marche pas toujours aussi bien : la JVM a été pensée pour Java et la viser depuis un autre langage peut poser problème si ta sémantique est vraiment différente. Typiquement tu ne vas pas pouvoir réutiliser le modèle objet (mais invoke_dynamic est censé aider pour ça), ou alors ton langage utilise beaucoup les appels terminaux qui ne sont pas optimisés en Java pour des raisons moisies, ou tu utilises des exceptions qui se traînent le ventre par terre sur la JVM ou sur la machine virtuelle .NET.
Même pour les langages dynamiques implémentés avec les pieds comme Python, PHP ou Ruby, les gens pensaient avoir de gros gains en utilisant un runtime "state of the art" comme Java ou un JIT existant comme LLVM, et en fait c'est loin d'être aussi simple, la perte de contrôle sur la représentation des données ou certains points d'optimisation fait que c'est finalement assez dur de faire franchement beaucoup mieux en peu d'efforts; et même quand tu y arrives, tu découvres que les utilisateurs ont codé les bouts performance-critiques en C en passant par une FFI toute moche reposant sur des détails internes de l'implémentation précédente, et t'es mort. C'est pour ça que les projets style Rubinius, JRuby, Pypy et compagnie ont la vie dure.
[^] # Re: Utilité ?
Posté par gasche . Évalué à 2.
Ah oui, et zut aux gens qui ont "inutilé" ton post à 0 alors que la question est légitime et que la dépêche ou les liens qu'elle fournit ne lui apporte pas vraiment de réponse claire.
[^] # Re: Utilité ?
Posté par claudex . Évalué à 3.
Même si je n'approuve pas, je pense que l'inutilage était dû au fait que la question revient à chaque nouvelle sur JRuby/Jython (même si c'est rarement aussi bien expliqué que ton post).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.